As a preliminary matter and for purposes of appeal, Applicant incorporates by reference 
the entire set of arguments in support of patentability that were presented in the previous 
response filed on February 19, 2004. 

In the present Office Action, the Examiner repeats the original rejection and at page 7, 
summarizes certain of the arguments and provides comments with respect to them. Applicants' 
reply is as follows, but not in the order given by the Examiner: 

Variable Number of Bytes in Error Code 

One notable distinction raised by the Applicant is that Birdwell does not teach a variable 
number of bytes in the error correction code, but that the number of bytes is fixed. Applicant has 
disclosed this feature in great detail at pages 11-16 of the present application. The Examiner 
responds with particular reference to col. 6, lines 12-26 of Birdwell that the reference teaches 
that a frame is broken into data fragments, which form blocks of the packets, and the last packet 
has an error correction trailer containing error correction data positioned after the data block. 

The Examiner's position does not address at all the distinction presented by the Applicant 

and the cited portion of Birdwell does not support the Examiner's assertion. First as to the text 

of Birdwell, Col. 6, lines 12-26 states as follows: 

The last MPT packet 140(n) has an error correction trailer 162 containing error 
correction data positioned after the data block 142(n). As an example, the error 
correction trailer 162 contains a 32-bit CRC (cyclic redundancy check) value that 
is computed for all preceding MPT packets 140(l)-140(n), which is represented as 
the bytes within dashed box 164. CRC error checking is a procedure used to 
check for errors in data transmission. It involves a complex calculation to 
generate a value based upon the data being transmitted. A CRC value is computed 
at the transmitter and attached as part of the transmitted packet. The receiver 
repeats the calculation and compares it to the attached CRC value. If the receiver's 
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calculation and the attached CRC value match, the transmission of data is 
assumed to be error-free. CRC is well known and widely used . It is noted that 
other types of error correction values can be alternatively employed, (emphasis 
added) 

Newton 's Telecom Dictionary defines CRC as follows: 

CRC Cyclic Redundancy Check. A process used to check the integrity of a block 
of data. A CRC character is generated at the transmission end. Its value depends 
on the hexadecimal value of the number of ones in the data block. The 
transmitting device calculates the value and appends it to the data block. The 
receiving end makes a similar calculation and compares its results with the added 
character. If there is a difference, the recipient requests retransmission. CRC is a 
common method of establishing that data was correctly received in data 
communications. See CRC Character. 



Clearly Birdwell teaches a FIXED LENGTH ERROR DETECTING CODE that is 
precisely 32-bit (see col. 6, line 14) and is fixed on the basis of the definition of CRC. There is 
no variable length error correction code as in the claimed invention. The application at page 3, 
lines 9-17 states : 

The frame format of the present invention also allows fast synchronization and the 
exchange of coding information. To enhance the quality of the satellite or wireless 
link, each frame contains Reed- Solomon (RS) check bytes used for error 
correction, that can be adaptively changed based on varying link conditions. The 
number of RS check bytes in a frame can be changed on the fly, without any loss 
of data, to compensate for varying link conditions. The link quality is monitored, 
and the observed link quality is used as the criterion for setting the number of RS 
check bytes in a frame. Further, several frames are interleaved before 
transmission over the satellite/wireless link to spread the effect of burst errors 
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over several frames, all of which can then be corrected by the forward error 
correction (FEC) in the frames, (emphasis added). 

Application to Frame Relay 

The Applicant distinguished Birdwelt for its failure to teach "frame relay" type 
transmissions, but the Examiner disagrees because the term is applied by the Telecom dictionary 
to services that employ a form of packet switching analogous to a X.25 network. The Examiner 
considers the packets in Birdwell to be "frames", which are variable length with the payload. 
The Examiner states that the network in Birdwell can accommodate data packets of various sizes 
and asserts that the network data configured in a packet having a data block and header has a 
variable length. 

Again, nowhere in the reference is there any mention of "frame relay," which is a 
distinctive type of transmission using variable length packets, as clearly disclosed throughout the 
present application. Thus, Birdwell is distinguishable, as it does not mention frame relay at all. 
The Examiner's statement that the "packets are frames" serves to emphasize the unconventional 
definitions and terminology, contrary to well established meanings of these terms, to formulate 
that rejection. Applicant simply states as to this point that there is no teaching or suggestion that 
the principles of Birdwell may be applicable to a frame relay application. 

Segmenting of Packets 

The Applicant asserted that Birdwell does not teach segmenting of packets and formation 
of smaller packets from each frame relay packet. The Examiner disagrees because the Examiner 
sees in Birdwell a process of breaking packets into smaller packets for use ' in a payload 
transported over a transmission distribution medium. 
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Again, the segmentation relates to frame relay packets, which are not disclosed as already 
noted. The Examiner's repeated citation of the teachings at col 3, lines 1-30 is unavailing 
because this feature relates to the formation of MPT packets that are of a size appropriate for 
transmission over the satellite system and are sized to 127 bytes. The Examiner has not 
addressed this specific deficiency in the broad and generalized dismissal of this clear distinction. 
As already noted, the process of Fig. 3, which is referenced by the Examiner, involves encoding 
the network data packet into a variable length MPT frame (step 102) and then encoding the MPT 
frame into fixed-length MPT packets (step 104), and finally embedding the MPT packets into 
satellite packets (step 106). The entire MPT packet is embedded into a 127 byte payload of a 
conventional 147 byte DSS packet. Thus, the packets are placed as the data payload within 
standard fixed-sized packets suitable for transmission across a particular distribution medium, 
such as the DSS network. Based on this description, the payload has a fixed length MPT packet 
and associated header information. Contrary to the Examiner's assertion, this DSS packet does 
not contain multiple MPT packets . Thus, the claimed step of forming fixed-sized 
satellite/wireless frames, each containing plural spackets, cannot be found in Birdwell. 

Priority of Frame Packets 

The Examiner admits that Birdwell fails to disclose queues with priorities . Applicant 
further argued that the use of priority offers a fundamental feature of the present invention, as it 
(1) indicates the recognition that different data should have priorities, (2) applies such priorities 
to the frame relay packets and, more importantly, (3) the subdivision of such packets in the form 
of "spackets." Applicant noted that Anderson does not remedy the deficiencies of Birdwell or 
otherwise teach how Birdwell could be modified to meet the claim limitations, even excluding 
the priority feature. 
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The Examiner disagrees because Anderson is seen to disclose an air interface, RF 
communication between mobile and base station where queuing and priorities are used to 
facilitate response to urgent signaling and control messages, as recited at col. 3, lines 45-58. 

However, this broad assertion with respect to a need for priority in Anderson does not 
remedy the fundamental deficiency already noted with respect to Anderson in combination with 
Birdwell. First, there is no teaching or suggestion for modifying Birdwell to implement anything 
like the priority of Anderson. Birdwell has no indication that different internet protocol data 
should be treated with different priorities. In the present case, Applicants first prioritizes and 
then segments, followed by scheduling and forming of fixed sized satellite/wireless frames. 

Second, even if combinable, the two references do not teach the order of steps in 
Applicants' invention. Specifically, there is no teaching of (1) receiving frame relay packets, (2) 
prioritizing the packets, (3) segmenting the payload to form spackets and (4) scheduling 
transmission of the spackets in accordance with the priorities of the frame relay packets to which 
the spackets correspond. This order is not found in Anderson. Moreover, because of this 
difference, it would not be obvious to one of ordinary skill in the art to modify Birdwell in a 
manner that could apply the teachings of Anderson. 

In view of the above, reconsideration and allowance of this application are now believed 
to be in order, and such actions are hereby solicited. If any points remain in issue which the 
Examiner feels may be best resolved through a personal or telephone interview, the Examiner is 
kindly requested to contact the undersigned at the telephone number listed below. 
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The USPTO is directed and authorized to charge all required fees, except for the Issue 
Fee and the Publication Fee, to Deposit Account No. 19-4880. Please also credit any 
overpayments to said Deposit Account. 

Respectfully submitted, 



SUGHRUE MION, PLLC 
Telephone: (202) 293-7060 
Facsimile: (202) 293-7860 

WASHINGTON OFFICE 

23373 

CUSTOMER NUMBER 



V A ^ O 



Alan J. Kasper 
Registration No. 25^,426 




Date: August 3, 2004 
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